Publish docs version 20.x

website/versioned_docs/version-20.x/guide/launch-args.md

@@ -41,5 +41,5 @@ Examples:
 
 Our official recommendation for getting the arguments inside the app is by integrating the [react-native-launch-arguments](https://github.com/iamolegga/react-native-launch-arguments) project, which provides that seamlessly. For those who are interested, here are the underlying details:
 
-- On iOS, the specified launch arguments are passed as the process launch arguments and available through normal means, such as accesing `[[NSProcessInfo processInfo] arguments]`.
+- On iOS, the specified launch arguments are passed as the process launch arguments and available through normal means, such as accessing `[[NSProcessInfo processInfo] arguments]`.
 - On Android, the launch arguments are set as bundle-extra’s into the activity’s intent. They are therefore accessible on the native side via the current activity as: `currentActivity.getIntent().getBundleExtra("launchArgs")`.

website/versioned_docs/version-20.x/guide/test-id.md

@@ -8,7 +8,7 @@ This guide was written primarily for React Native apps, but it can be generalize
 
 While [view-element matching](../api/matchers.md) can be done in numerous ways, it is always the best idea to match based on something unique and decoupled, as it ensures that the test code is clear, stable and sustainable over time.
 
-We recommend assigning unique test ID's to the elements you're aiming to interact with in your tests, and prefering matching based on those rather than on anything else. Test ID's are the least likely to change over time (compared with raw text, for example), and are locale-agnostic. Furthermore, utilizing unique test ID's across the app not only simplifies the identification and interaction with specific elements but also enhances code navigability, making it easier to locate elements when traversing the codebase.
+We recommend assigning unique test ID's to the elements you're aiming to interact with in your tests, and preferring matching based on those rather than on anything else. Test ID's are the least likely to change over time (compared with raw text, for example), and are locale-agnostic. Furthermore, utilizing unique test ID's across the app not only simplifies the identification and interaction with specific elements but also enhances code navigability, making it easier to locate elements when traversing the codebase.
 
 In React Native applications, `View` components have a dedicated [test ID property](https://reactnative.dev/docs/view#testid) that can be utilized:
 

website/versioned_docs/version-20.x/introduction/your-first-test.mdx

@@ -58,7 +58,7 @@ If your app supports deep links, you can configure it to [start from a specific
 
 :::tip
 
-It is a good idea to start every test from a fresh state, since the preceeding ones might leave your application
+It is a good idea to start every test from a fresh state, since the preceding ones might leave your application
 in an unpredictable state if they fail.
 
 One way to do it is to launch the app as a new instance in `beforeEach` hook instead: