Merge branch 'main' of https://github.com/graphprotocol/docs

Author: benface

pages/ar/developer/assemblyscript-migration-guide.mdx

@@ -180,7 +180,8 @@ let c: usize = a + (b as usize)
 // upcasting on class inheritance
 class Bytes extends Uint8Array {}
 
-let bytes = new Bytes(2) < Uint8Array > bytes // same as: bytes as Uint8Array
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
 ```
 
 هناك سيناريوهين قد ترغب في ال cast ، ولكن استخدام `as`/`<T>var` ** ليس آمنا **:
@@ -192,15 +193,17 @@ let bytes = new Bytes(2) < Uint8Array > bytes // same as: bytes as Uint8Array
 // downcasting on class inheritance
 class Bytes extends Uint8Array {}
 
-let uint8Array = new Uint8Array(2) < Bytes > uint8Array // breaks in runtime :(
+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 :(
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
 ```
 
 في هذه الحالة يمكنك إستخدام دالة `changetype<T>`:

pages/ar/developer/subgraph-debug-forking.mdx

@@ -1,28 +1,28 @@
 ---
-title: Quick and easy subgraph debugging using forks
+title: تصحيح أخطاء الـ subgraph بسرعة وسهولة باستخدام التفرعات (forks)
 ---
 
-> Note: this is only available from this `graph-node` [commit](https://github.com/graphprotocol/graph-node/commit/f4e6992d7949b18f990045c8babdcd205a060ef6) or this [docker tag](https://hub.docker.com/layers/graphprotocol/graph-node/f4e6992/images/sha256-51ad494a2ecc387bef2359d863b596ad5bd44436808964cf221e60365a7c00c8?context=explore) onwards, it hasn't been yet released in a minor release (eg: 0.26.0)
+> ملاحظة: هذا متاح فقط من هذا `graph-node` [commit](https://github.com/graphprotocol/graph-node/commit/f4e6992d7949b18f990045c8babdcd205a060ef6) أو هذا [docker tag](https://hub.docker.com/layers/graphprotocol/graph-node/f4e6992/images/sha256-51ad494a2ecc387bef2359d863b596ad5bd44436808964cf221e60365a7c00c8?context=explore) وصاعدا ولم يتم إصدارها بعد في إصدار ثانوي (على سبيل المثال: 0.26.0)
 
-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) بعض الوقت لمزامنة الـ subgraph الخاص بك مع blockchain المستهدف. التناقض بين التغييرات السريعة بغرض تصحيح الأخطاء وأوقات الانتظار الطويلة اللازمة للفهرسة يؤدي إلى نتائج عكسية للغاية ونحن ندرك ذلك جيدًا. ولهذا السبب نقدم **subgraph forking ** ، الذي تم تطويره بواسطة [ LimeChain ](https://limechain.tech/) ، وفي هذه المقالة سنوضح لكم كيف يمكن استخدام هذه الميزة لتسريع تصحيح أخطاء الـ subgraph بشكل كبير!
 
-## Ok, what is it?
+## حسنا، ما هو؟
 
-**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+**Subgraph forking** هي عملية جلب الكيانات بشكل lazily من مخزن subgraph _آخر_ (عادةً ما يكون بعيدًا).
 
-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_.
+يسمح لك **subgraph forking** بتصحيح أخطاء الـ subgraph الفاشل في الكتلة(block) _ X _ دون الحاجة للانتظار للمزامنة للكتلة _ 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_.
+عندما تنشر subgraph إلى Graph node بعيدة للقيام بالفهرسة ويفشل عند الكتلة _ X _ ، فإن الخبر الجيد هو أن Graph node ستظل تقدم استعلامات GraphQL باستخدام مخزنها(store)، والذي تمت مزامنته للكتلة(block) _ 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.
+باختصار ، سنقوم _ بتفريع (fork) الـ subgraph الفاشل _ من Graph node بعيدة والتي تضمن فهرسة الـ subgraph للكتلة _ X _ وذلك من أجل توفير الـ subgraph المنشور محليًا والذي يتم تصحيحه عندالكتلة*X* مع عرض محدث لحالة الفهرسة.
 
-## 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/example-subgraph) indexing the Ethereum Gravity smart contract.
+للاستمرار في التركيز على تصحيح أخطاء الـ subgraph ، دعنا نجعل الأمور بسيطة ونعمل مع [example-subgraph](https://github.com/graphprotocol/example-subgraph) الذي يفهرس عقد Ethereum Gravity الذكي.
 
-Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+فيما يلي المعالجات (handlers) المعرفة لفهرسة `Gravatar` ، بدون أخطاء على الإطلاق:
 
 ```tsx
 export function handleNewGravatar(event: NewGravatar): void {
@@ -46,43 +46,43 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 }
 ```
 
-Oops, how unfortunate, when I deploy my perfect looking subgraph to the [HostedService](https://thegraph.com/hosted-service/) it fails with the _"Gravatar not found!"_ error.
+للأسف ، يفشل نشر هذا الـ subgraph ذو المظهر المثالي على [ HostedService ](https://thegraph.com/hosted-service/)مع ظهور الخطأ _"Gravatar not found!"_.
 
-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 the [HostedService](https://thegraph.com/hosted-service/) (or another remote Graph node).
-3. Wait for it to sync-up.
-4. If it breaks again go back to 1, otherwise: Hooray!
+1. إجراء تغيير في مصدر الـ mappings ، والذي تعتقد أنه سيحل المشكلة (وأنا أعلم أنه لن يحلها).
+2. إعادة نشر الـ subgraph على [ HostedService ](https://thegraph.com/hosted-service/) (أو 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:
+باستخدام **subgraph forking** يمكننا التخلص من تلك الخطوة. إليك كيف يبدو:
 
-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!
+0. قم بتجهيز Graph node محلية بمجموعة **_fork-base_** مناسبة.
+1. قم بإجراء تغيير في مصدر الـ mappings ، والذي تعتقد أنه سيحل المشكلة.
+2. قم بالنشر إلى Graph node محلية ، **_وقم بتفريع الـ subgraph الفاشل_**و**_ البدء من الكتلة التي بها المشكلة_**.
+3. إذا حدثت المشكلة مرة أخرى ، فارجع إلى 1!
 
-Now, you may have 2 questions:
+الآن ، قد يكون لديك سؤالان:
 
-1. fork-base what??? 2) Forking who?!
-2. Forking who?!
+1. ماهو fork-base؟؟؟
+2. ما الذي نقوم بتفريعه (Forking)؟!
 
-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:
-2. Forking is easy, no need to sweat:
+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
 ```
 
-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` في subgraph manifest لرقم الكتلة(block) التي بها المشكلة، حتى تتمكن من تخطي فهرسة الكتل الغير ضرورية والاستفادة من التفريع!
 
-So, here is what I do:
+لذلك ، هذا ما أفعله:
 
-0. 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 the [HostedService](https://thegraph.com/hosted-service/).
+0. أقوم بتجهيز Graph Node محلية ([هنا كيف تقوم به](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) مع تعيين خيار `fork-base` إلى `https://api.thegraph.com/subgraphs/id/` ، نظرا لأنني سأقوم بتفريع(fork) الـ subgraph الذي به أخطاء والذي نشرته سابقا من الـ [HostedService](https://thegraph.com/hosted-service/).
 
 ```
 $ cargo run -p graph-node --release -- \
@@ -92,13 +92,13 @@ $ cargo run -p graph-node --release -- \
     --fork-base https://api.thegraph.com/subgraphs/id/
 ```
 
-1. 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. 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`:
+1. بعد فحص دقيق ، لاحظت أن هناك عدم تطابق في تمثيلات الـ `id` المستخدمة عند فهرسة `Gravatar` في المعالجين الخاصين بي. بينما `handleNewGravatar` يحول (`event.params.id.toHex()`) إلى سداسي ، `handleUpdatedGravatar` يستخدم int32 (`event.params.id.toI32()`) مما يجعل `handleUpdatedGravatar` قلقا من "Gravatar not found!". أنا أجعلهم كلاهما يحولان `id` إلى سداسي.
+2. بعد إجراء التغييرات ، قمت بنشر الـ subgraph الخاص بي على Graph node المحلية **_وتفريع الـsubgraph الفاشل_** وضبط `dataSources.source.startBlock` إلى `6190343` في `subgraph.yaml`:
 
 ```bash
   $ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
 ```
 
-3. I inspect the logs produced by the local Graph node and, Hooray!, everything seems to be working.
-4. I deploy my now bug-free subgraph to a remote Graph node and live happily ever after! (no potatoes tho)
-5. The end...
+3. لقد قمت بفحص السجلات التي تنتجها Graph node المحلية ، ويبدو أن كل شيء يعمل بشكل جيد.
+4. أقوم بنشر الـ subgraph الخاص بي الخالي من الأخطاء لـ Graph node بعيدة وأعيش في سعادة دائمة
+5. النهاية...

pages/ar/hosted-service/migrating-subgraph.mdx

@@ -137,7 +137,7 @@ _بينما تتم هذه الآلية حاليا على الشبكة ، ينا
 
 على الرغم من أن هذه ليست ميزة موجودة في واجهة مستخدم المنتج ، إلا أنه يمكنك تعيين الحد الأقصى لميزانيتك لكل استعلام وذلك عن طريق أخذ المبلغ الذي ترغب في دفعه شهريًا وتقسيمه على حجم الاستعلام المتوقع.
 
-While you get to decide on your query budget, there is no guarantee that an Indexer will be willing to serve queries at that price. If a Gateway can match you to an Indexer willing to serve a query at, or lower than, the price you are willing to pay, you will pay the delta/difference of your budget **and** their price. As a consequence, a lower query price reduces the pool of Indexers available to you, which may affect the quality of service you receive. It's beneficial to have high query fees, as that may attract curation and big-name Indexers to your subgraph.
+أثناء اتخاذ قرار بشأن ميزانية الاستعلام الخاصة بك ، ليس هناك ما يضمن أن المفهرس سيكون على استعداد لتقديم الاستعلامات بهذا السعر. إذا تمكن الـ Gateway من مطابقتك مع مفهرس يرغب في تقديم استعلام بالسعر الذي ترغب في دفعه أو أقل ، فستدفع الفرق بين ميزانيتك **و** سعرهم. ونتيجة لذلك ، فإن سعر الاستعلام المنخفض يقلل من عدد المفهرسين المتاحين لك ، مما قد يؤثر على جودة الخدمة التي تتلقاها. من المفيد أن يكون لديك رسوم استعلام مرتفع ، لأن ذلك قد يجذب التنسيق وأسماء كبيرة من المفهرسين إلى الـ subgraph الخاص بك.
 
 تذكر أنه سوق ديناميكي ومتنامي ، ولكن كيفية تفاعلك معه هو تحت سيطرتك. لا يوجد حد أقصى أو أدنى للسعر في البروتوكول أو البوابات(Gateways). على سبيل المثال ، يمكنك إلقاء نظرة أدناه على السعر الذي دفعه عدد قليل من الـ dapps على الشبكة (على أساس أسبوعي). انظر للعمود الأخير ، والذي يعرض رسوم الاستعلام كـ GRT. على سبيل المثال ، [Pickle Finance](https://www.pickle.finance/) لديه 8 طلبات في الثانية ودفع 2.4 GRT لأسبوع واحد.