fix formatting and auto-validation fixes

Author: BrandtH22

.github/workflows/crowdin-pull.yml

@@ -86,7 +86,7 @@ jobs:
 
       - name: Validate translations
         run: |
-          npm run validate:translations || (echo "Translation validation failed. Please check the errors above." && exit 1)
+          npm run validate:translations || (echo "Translation validation failed. The validate-translations workflow will auto-fix issues when the PR is created." && exit 1)
 
       - name: Commit and push formatted and compiled translations
         run: |

i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/foliage.md

@@ -66,7 +66,7 @@ The average time between transaction blocks is 52 seconds. Several values are re
 - Sub-slot time = 600 seconds
 - Signage point time = 64 per sub-slot, or 600/64 = 9.375 seconds
 - Average block time = 32 per sub-slot, or 600/32 = 18.75 seconds
-- Minimum signage points from current signage point until infusion_iterations is reached = 3 (See the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md) for more info.)
+- Minimum signage points from current signage point until infusion_iterations is reached = 3 (See the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points.md) for more info.)
 - Minimum time for infusion_iterations to be reached (and therefore, minimum time between transaction blocks) = 3 \* (600/64) = 28.125 seconds
 - Average signage points until infusion_iterations is reached is slightly more than 3.5 (must wait 3 signage points, plus an average wait of about 50% of the next signage point), or around 3.5 \* 9.375 = 32.8125 seconds.
 - To create a transaction block, infusion_iterations first must be met, and then the next block some seconds afterwards will be a transaction block. The total average time for this to happen is around 52 seconds.

i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/harvester-algorithm.md

@@ -26,5 +26,5 @@ class NewSignagePointHarvester:
 
 `plot filter bits = sha256(plot_id + challenge_hash + sp_hash)`.
 
-If the resulting bits start with 9 zeroes, then the plot passes the filter. This does not require disk access, since the plot_ids are stored in memory. 2. For each of the plots passing the filter, a new thread is started, which performs the quality lookups. Recall that this requires around 7-9 random reads into the plot, one for each table. This is where the majority of the disk activity will be. On average, 1 of every 512 plots will perform this step. 3. required_iterations is computed, as explained in the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md). If the farmer is currently farming for a pool, then the pool will use custom values for both `difficulty` and `sub-slot_iterations`. These values make it more likely that a proof will be found. The reason to use these values is to make it easier for the pool to determine the amount of storage a farmer currently has dedicated.
+If the resulting bits start with 9 zeroes, then the plot passes the filter. This does not require disk access, since the plot_ids are stored in memory. 2. For each of the plots passing the filter, a new thread is started, which performs the quality lookups. Recall that this requires around 7-9 random reads into the plot, one for each table. This is where the majority of the disk activity will be. On average, 1 of every 512 plots will perform this step. 3. required_iterations is computed, as explained in the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points.md). If the farmer is currently farming for a pool, then the pool will use custom values for both `difficulty` and `sub-slot_iterations`. These values make it more likely that a proof will be found. The reason to use these values is to make it easier for the pool to determine the amount of storage a farmer currently has dedicated.
 If required_iterations is less than the interval_iterations, this proof of space is good (it has won either a pool partial or a block). Most proofs will not pass this step. 5. For winning proofs, the whole proof is fetched on disk (approximately 64 random reads in the plot). 6. The proof is sent back to the farmer.

i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/multiple-blocks.md

@@ -19,7 +19,7 @@ VDF proofs span:
 
 In the example in Figure 7, B2 contains a VDF proof from B1 to sp2, and from B1 to B2. B3 contains a proof from B1 to sp3, and from B2 to B3. B2 does not depend at all on B3, but B3 depends on B2, since its VDF is from B2's infusion point.
 
-As discussed in [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md), the blocks get created at the signage points, but they are missing the infusion point VDF. Once this VDF is added, the block is finished, and forms part of the blockchain.
+As discussed in [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points.md), the blocks get created at the signage points, but they are missing the infusion point VDF. Once this VDF is added, the block is finished, and forms part of the blockchain.
 
 The signatures get created and added by the farmers at the signage points, and broadcast to the whole network.
 There are no signatures at the infusion point; the only things added at the infusion point are the VDFs.

i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/overflow-blocks.md

@@ -5,7 +5,7 @@ slug: /chia-blockchain/consensus/chains/overflow-blocks
 
 ## Overflow Blocks
 
-For a farmer to create a block, their required_iterations must be less than sub-slot_iterations / 64, as described in the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md). This means that infusion_iterations might be greater than the sub-slot_iterations, and therefore the infusion must happen in the next sub-slot.
+For a farmer to create a block, their required_iterations must be less than sub-slot_iterations / 64, as described in the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points.md). This means that infusion_iterations might be greater than the sub-slot_iterations, and therefore the infusion must happen in the next sub-slot.
 
 **Overflow block**: a block whose infusion point is in a different sub-slot than its signage point.
 

i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-1.0.md

@@ -47,7 +47,7 @@ For each eligible plot (explained later), a farmer uses the following procedure
 7. For each matching f7 value, read T7 at the same index where the f7 value was found in its own table, and grab that entry, which is an index into T6
 8. The T6 index contains one _line point_ with two _back pointers_ to T5, four to T4, eight to T3, sixteen to T2 and thirty-two to T1. Each back pointer requires 1 read, so a total of 64 disk reads (1 index from T7, 63 back pointers) are performed to fetch the whole tree of 64 x-values.
 
-Since most proofs generated by this process are not good enough (as discussed in the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md)) to be submitted to the network for verification, we can optimize this process by only checking one branch of the tree. This branch will return two of the 64 x-values. The position of the x-values will always be consecutive and will depend on the signage point (eg x0 and x1... or x34 and x35). We hash these x-values to produce a random 256-bit "quality string." This is combined with the difficulty and the plot size to generate the required_iterations. If the required_iterations is less than a certain number, the proof can be included in the blockchain. At this point, we look up the whole proof of space.
+Since most proofs generated by this process are not good enough (as discussed in the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points.md)) to be submitted to the network for verification, we can optimize this process by only checking one branch of the tree. This branch will return two of the 64 x-values. The position of the x-values will always be consecutive and will depend on the signage point (eg x0 and x1... or x34 and x35). We hash these x-values to produce a random 256-bit "quality string." This is combined with the difficulty and the plot size to generate the required_iterations. If the required_iterations is less than a certain number, the proof can be included in the blockchain. At this point, we look up the whole proof of space.
 
 By only looking up one branch to determine the quality string, we can rule out most proofs. This optimization requires only around 7-9 disk seeks and reads, or about 70-90 ms on a slow hard drive.
 
@@ -57,7 +57,7 @@ Throughout this website, we'll make a simple assumption that a single disk seek
 The 10ms estimate also takes into account the time required to transfer data after the seek. While storage industry specs typically assume that large files are being transferred, this does not hold true for Chia farming, where proof lookups only require a tiny amount of data to be transferred. Therefore, for this website, it's safe to assume the transfer is almost instant.
 :::
 
-Chia also uses a further optimization to disqualify a certain proportion of plots from eligibility for each challenge. This is referred to as the _plot filter_. The current requirement is that the hash of the plot ID, challenge, and signage point starts with 9 zeros. This excludes 511 out of every 512 plots. The filter hurts everyone equally (except for [replotting attackers](/chia-blockchain/consensus/attacks-and-countermeasures#replotting)), and is therefore fair. The plot filter is discussed in greater detail in the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md).
+Chia also uses a further optimization to disqualify a certain proportion of plots from eligibility for each challenge. This is referred to as the _plot filter_. The current requirement is that the hash of the plot ID, challenge, and signage point starts with 9 zeros. This excludes 511 out of every 512 plots. The filter hurts everyone equally (except for [replotting attackers](/chia-blockchain/consensus/attacks-and-countermeasures#replotting)), and is therefore fair. The plot filter is discussed in greater detail in the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points.md).
 
 The plot filter effectively reduces the amount of resources required for farming by 512x -- each plot only requires a few disk reads every few minutes. A farmer with 1 PiB of storage (10,000 plots) will only have an average of 20 plots that pass the filter for each challenge. Even if these plots all are stored on slow HDDs, and connected to a single Raspberry Pi, the average time required to respond to each challenge will be less than two seconds. This is well within the limits to avoid missing out on any challenges.
 

i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/recovering-from-51-percent-attacks.md

@@ -13,11 +13,10 @@ We discussed in §2 the main security issues of a PoSpace based longest-chain b
 {' '}
 
 <figure>
-  <img src='/img/green-paper/table-1.png' />![](/img/green-paper/table-1.png) 
+  <img src='/img/green-paper/table-1.png' />
   <figcaption>
     Table 1: Summary of the ability to heal from malicious majority and provide security under dynamic availability of longest-chain protocols based various proof systems.
   </figcaption>
-  </figcaption>
 </figure>
 
 ## 6.1 Recovery from $51\%$ Attacks

i18n/zh-Hans/docusaurus-plugin-content-docs/current/dev-guides-home.md

@@ -29,7 +29,7 @@ import SimulatorGuide from '@site/static/img/home_pages/simulator_guide.png';
 import WalletConnect from '@site/static/img/home_pages/wallet_connect.png';
 
 import GreatChia from '@site/static/img/home_pages/chia_great.png';
-import AppDev from '@site/static/img/home_pages/dev_on_chia.png';
+import AppDev from '@site/static/img/home_pages/chia_dev.png';
 import ToolsSetup from '@site/static/img/home_pages/env_setup.png';
 import ProgrammingClsp from '@site/static/img/home_pages/clsp_programming.png';
 import CoinLifecycle from '@site/static/img/home_pages/coin_lifecycle.png';

i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cr-cat-tutorial.md

@@ -206,7 +206,7 @@ Chia Wallet:
 
 ### CAT Admin Tool
 
-CR-CATS are issued from the CAT-admin-tool repository. Follow the instructions below to install it for your specific OS: Follow the instructions below to install it for your specific OS:
+CR-CATS are issued from the CAT-admin-tool repository. Follow the instructions below to install it for your specific OS:
 
 <Tabs
 defaultValue="mac"
@@ -249,19 +249,6 @@ python3 -m pip install --upgrade pip setuptools wheel
 
 Install the CAT admin tool:
 
-````bash
-pip install .
-``` ./venv/bin/activate
-````
-
-Install all prerequisites:
-
-```bash
-python3 -m pip install --upgrade pip setuptools wheel
-```
-
-Install the CAT admin tool:
-
 ```bash
 pip install .
 ```
@@ -305,8 +292,6 @@ Install the CAT admin tool:
 pip install .
 ```
 
-````
-
   </TabItem>
 </Tabs>
 

i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/prefarm-audit.md

@@ -91,7 +91,7 @@ NOTE: A high level of technical proficiency is needed to understand the details
       4. `BASE_REKEY_TIMELOCK` = integer of the rekey timelock.
       5. `SLOW_REKEY_PENALTY` = integer of the slow rekey penalty.
 3. Curry the necessary parameters into singleton_top_layer_v1_1.clsp `(SINGLETON_STRUCT INNER_PUZZLE)`:
-   1. `SINGLETON_STRUCT` = a tree with the following elements in order `(MOD_HASH . (LAUNCHER_ID . LAUNCHER_PUZZLE_HASH))`: (LAUNCHER_ID . LAUNCHER_PUZZLE_HASH))</code>:
+   1. `SINGLETON_STRUCT` = a tree with the following elements in order `(MOD_HASH . (LAUNCHER_ID . LAUNCHER_PUZZLE_HASH))`:
       1. `MOD_HASH` = singleton_top_layer puzzle sha256 tree hash without its curried arguments.
       2. `LAUNCHER_ID` = the ID of the singleton we are committed to paying.
       3. `LAUNCHER_PUZZLE_HASH` = the puzzle hash of the launcher.