Merge branch 'main' into patch-7

content/md/en/docs/learn/accounts-addresses-keys.md

@@ -20,7 +20,7 @@ The secret seed phrase is important because it can be used to recover access to
 
 For most networks, the **public key** associated with an account is how that account is identified on the network and some form of it is used as the destination address for transactions.
 However, Substrate-based chains use the underlying public key to derive one or more **public addresses**.
-Instead of using the public key directly, Substrate allows you generate multiple addresses and address formats for an account.
+Instead of using the public key directly, Substrate allows you to generate multiple addresses and address formats for an account.
 
 ## Address encoding and chain-specific addresses
 
@@ -74,7 +74,7 @@ For more information about working with generic types, see [Rust for Substrate](
 
 ## Specialized accounts
 
-As a flexible and module framework for blockchain development, Substrate itself doesn't require you define or use any specific type of accounts.
+As a flexible and module framework for blockchain development, Substrate itself doesn't require you to define or use any specific type of accounts.
 However, different chains can implement different rules for how accounts and the keys that control them are used.
 For example, you might implement specialized accounts if your application requires:
 

content/md/en/docs/learn/rust-basics.md

@@ -17,7 +17,7 @@ Being the language of choice for Substrate, Rust is a highly performant programm
 
 ## Rust in Substrate
 
-In the [Architecture]() section, you will learn that Substrate is made of two distinct architectural components: the outer node and the runtime.
+In the [Architecture](/learn/architecture/) section, you will learn that Substrate is made of two distinct architectural components: the outer node and the runtime.
 While more complex features in Rust such as multithreading and asynchronous Rust are used in the outer node code, they aren't directly exposed to runtime engineers, making it easier for runtime engineers to focus on the business logic of their node.
 
 Generally, depending on their focus, developers should expect to know:
@@ -40,7 +40,7 @@ These macros allow you to focus on writing idiomatic Rust and application-specif
 
 Rust macros are a powerful tool to help ensure certain requirements are met (without re-writing code) such as the logic to be formatted in a specific way, specific checks are made, or some logic consists of specific data structures.
 This is especially useful to help developers write code that can integrate with the complexity of a Substrate runtime.
-For example, the `#[frame_system::pallet]` macro is required in all FRAME pallets to help you correctly implement certain required attributes-such as storage items or externally callable functions-and make it compatible with the build process in `construct_runtime`.
+For example, the `#[frame_support::pallet]` macro is required in all FRAME pallets to help you correctly implement certain required attributes-such as storage items or externally callable functions-and make it compatible with the build process in `construct_runtime`.
 
 Developing Substrate runtimes involves heavy use of Rust's attribute macros, which come in two flavors: derive attributes and custom attributes.
 When you're getting started with Substrate, it isn't so important to know exactly how they work, but rather to know that they exist that they empower you to write correct runtime code.

content/md/en/docs/learn/transaction-lifecycle.md

@@ -81,8 +81,8 @@ If a transaction is invalid—for example, because it is too large or doesn't co
 A transaction might be rejected for any of the following reasons:
 
 - The transaction has already been included in a block so it is dropped from the verifying queue.
-- The transaction's signature is invalid, so it is immediately be rejected.
-- The transaction is too large to fit in the current block, so it is be put back in a queue for a new verification round.
+- The transaction's signature is invalid, so it is immediately rejected.
+- The transaction is too large to fit in the current block, so it is put back in a queue for a new verification round.
 
 ## Transactions ordered by priority
 
@@ -136,7 +136,7 @@ Before committing any state changes to storage, the runtime logic should perform
 
 Note that [events](/build/events-and-errors/) are also written to storage.
 Therefore, the runtime logic should not emit an event before performing the complementary actions.
-If a transaction fails after an event is emitted, the event is not be reverted.
+If a transaction fails after an event is emitted, the event is not reverted.
 
 ### Finalizing a block