docs: fix documentation typos

docs/ab-testing.md

@@ -7,7 +7,7 @@ This guide explains how to implement server-side A/B tests on ethereum.org using
 Our A/B testing system provides:
 
 - **Server-side rendering** - Users see consistent variants on first page load with no layout shifts
-- **Matomo API integration** - Tests configured entirely in Matomo dashboard, no code deployments needed
+- **Matomo API integration** - Tests are configured entirely in the Matomo dashboard; no code deployments are needed
 - **GDPR compliance** - Cookie-less tracking using deterministic fingerprinting (IP + User-Agent)
 - **Multi-variant support** - Test 2+ variations with configurable weights / traffic splits
 - **Real-time updates** - Adjust experiment weights instantly via Matomo dashboard
@@ -134,7 +134,7 @@ Supports 3+ variants:
 
 1. Create your experiment in Matomo (set to "running")
 2. Implement `ABTestWrapper` in your component
-3. Test locally - the debug panel shows current assignment
+3. Test locally - the debug panel shows the current assignment
 4. Adjust weights in Matomo dashboard to test different scenarios
 
 ### Preview Mode
@@ -146,7 +146,7 @@ Supports 3+ variants:
 ### Production
 
 1. Deploy your component with `ABTestWrapper`
-2. Monitor experiment in Matomo dashboard
+2. Monitor the experiment in the Matomo dashboard
 3. Adjust traffic allocation as needed
 4. Analyze results and implement winning variant
 
@@ -224,7 +224,7 @@ NEXT_PUBLIC_IS_PREVIEW_DEPLOY=false
 
 1. **Check environment variables**: Ensure all Matomo config is set
 2. **Verify API token**: Must have "experiments" permission in Matomo
-3. **Check cache**: API responses cached for 1 hour, use dev mode for real-time updates
+3. **Check cache**: API responses are cached for 1 hour, use dev mode for real-time updates
 4. **Fallback behavior**: When API fails, all tests show original variant (safe default)
 
 ## Debug Panel

docs/api-keys.md

@@ -1,4 +1,4 @@
-# APIs we use in our website
+# APIs we use on our website
 
 ## Environment File Structure
 
@@ -11,7 +11,7 @@ This project uses two separate `.env.local` files:
 
 Some variables like `GITHUB_TOKEN_READ_ONLY` and Sentry config are shared and should be set in both files.
 
-See `src/data-layer/.env.example` for all data-layer specific variables.
+See `src/data-layer/.env.example` for all data-layer-specific variables.
 
 ---
 

docs/applying-storybook.md

@@ -2,15 +2,15 @@
 
 ## Overview
 
-StorybookJS is a UI tool for isolating UI components to visually test its styles and states.
+StorybookJS is a UI tool for isolating UI components to visually test their styles and states.
 
 This is great for checking the various iterations of a component in a sandbox versus scouring all the pages in a large scale project it is used to verify that the component is rendering properly.
 
 You can also render pages if you need that level of visual testing.
 
 Storybook also gives you a library of addons provided by the team and the community to enhance the testing, including UX testing, A11y compliance, etc.
 
-Check out [Intro to Storybook](https://storybook.js.org/tutorials/intro-to-storybook/) to get an in-depth look on the workflow.
+Check out [Intro to Storybook](https://storybook.js.org/tutorials/intro-to-storybook/) to get an in-depth look at the workflow.
 
 ## Spinning up the Storybook server
 
@@ -35,7 +35,7 @@ src/
         └── // Any other files as applicable (utils, child components, useHook, etc.)
 ```
 
-The initial structure of each story file will look something like this (in typescript):
+The initial structure of each story file will look something like this (in TypeScript):
 
 ```tsx
 import ComponentA from "."
@@ -55,7 +55,7 @@ export const Basic: Story = {}
 - With the `title` option, we write this based on the groupings set by the Design System. Groupings are declared with forward slashes. (i.e., `Atoms / Form / Input`). See the Storybook docs for details on [Naming conventions](https://storybook.js.org/docs/7.0/react/writing-stories/naming-components-and-hierarchy)
 - The `satisfies` TypeScript keyword is used with the `Meta` type for stricter type checking. This is particularly helpful to make sure required args are not missed. [Storybook Docs regarding `satisfies`](https://storybook.js.org/docs/writing-stories/typescript#using-satisfies-for-better-type-safety)
 - The use of `StoryObj` is to be able to typecheck the creation of a story as an object. This helps with prop inference.
-- We use `StoryObj<typeof meta>` in the event a required arg is provided in the `meta` object, to be applied to all stories in the file. This prevents type errors throwing at the story level for a required missing arg.
+- We use `StoryObj<typeof meta>` in the event a required arg is provided in the `meta` object, to be applied to all stories in the file. This prevents type errors from being thrown at the story level for a required missing arg.
 - If the story does not need any args or any custom rendering, it should be left as an empty object. Otherwise, use the `render` option to explicitly write the rendering of the story: i.e., `render: () => <Component />`
 
 Also, please view the Figma file for the [proposed structure for the Design System](https://www.figma.com/file/Ne3iAassyfAcJ0AlgqioAP/DS-to-storybook-structure?type=design&node-id=42%3A50&mode=design&t=RGkyouvTilzF42y0-1) to provide the correct groupings.
@@ -96,7 +96,7 @@ export const Outline: Story = {
  * For practical purposes, if you are displaying different "variants",
  * they should be shown under one story, so they can be seen side-by-side in the GUI
  * for reviewers to easily compare.
- * This can also be done for various sizes or other like alterations
+ * This can also be done for various sizes or other similar alterations
  *
  * 🚨 If prop content is supplied directly to the component and the `args` prop is not used,
  * use `StoryObj` without a prop type. This is especially important when a story renders multiple versions
@@ -142,7 +142,7 @@ The dashboard where you view each story has a number of different addons availab
 
 ![Screenshot of Storybook Dashboard for Ethereum.org](https://github.com/ethereum/ethereum-org-website/assets/65234762/7dea7692-6a6d-4f1c-b7cb-db177bcab44d)
 
-Outlined below are each area going from left to right in the selections.
+Outlined below are each of the areas going from left to right in the selections.
 
 | Toolbar above the preview                | Panel below the preview                                                                                                                                                                                                                                                    |
 | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -171,7 +171,7 @@ Depending on the component, we might look for more than just one snapshot per st
 
 You will currently find the setup of these modes in [the `./storybook/modes.ts` file](../.storybook/modes.ts)
 
-> Note: At this time we are only considering modes for viewport and languages. Color mode is not possible with the existing setup and is being investigated on making it available, should we want to use it.
+> Note: At this time we are only considering modes for viewport and languages. Color mode is not possible with the existing setup and is being investigated to make it available, should we want to use it.
 
 When using a mode at either the component level (all stories in a given file) or at the story level, they are supplied under the `chromatic` parameter.
 
@@ -196,7 +196,7 @@ const meta = {
 } satisfies Meta<typeof ContentHeroComponent>
 ```
 
-In this example, we are supplying all the combinations of the languages and viewports together in snapshots. These will only be viewed in chromatic and cannot be seen when viewing storybook locally.
+In this example, we are supplying all the combinations of the languages and viewports together in snapshots. These will only be viewed in Chromatic and cannot be seen when viewing Storybook locally.
 
 If needs to be only a couple of options, you can write them like this:
 

docs/best-practices.md

@@ -26,7 +26,7 @@ Markdown will be translated as whole pages of content, so no specific action is
       ```
         JSON `"page-warning": "BE VERY CAREFUL"`
       ```
-  - This minimizes issues during translation, and allows consistent styling to all languages
+  - This minimizes issues during translation, and allows consistent styling across all languages
 - _Please avoid_ embedding links within a sentence. For a word/phrase to be a link, it requires a key/string in the intl JSON. If this is in the middle of another sentence, this results in the sentence being broken into multiple pieces, and requires coding the sentence structure into the JavaScript.
 
   - This results in significant challenges during the translation process, as written syntax for each language will vary in terms of ordering subjects/verbs/etc.
@@ -39,7 +39,7 @@ Markdown will be translated as whole pages of content, so no specific action is
   </p>
   ```
 
-  Once, you've added your English content to the appropriate JSON file, the above code should look something more like:
+  Once you've added your English content to the appropriate JSON file, the above code should look something more like:
 
   ```tsx
   <p>
@@ -52,7 +52,7 @@ Markdown will be translated as whole pages of content, so no specific action is
 
   - _tl;dr Each individual JSON entry should be a complete phrase by itself_
 
-- This is done using the `Translation` component. However there is an alternative method for regular JS: using the `t` function from `@/hooks/useTranslation`
+- This is done using the `Translation` component. However, there is an alternative method for regular JS: using the `t` function from `@/hooks/useTranslation`
 
   - **Method one: `<Translation />` component (preferred if only needed in JSX)**
 
@@ -213,7 +213,7 @@ Use tailwind classes to size icons:
 
 ### Background Circles
 
-Wrap icon in a div for circular backgrounds, and color using background:
+Wrap an icon in a div for circular backgrounds, and color using background:
 
 ```tsx
 <div className="bg-primary/10 grid size-10 place-items-center rounded-full">
@@ -223,7 +223,7 @@ Wrap icon in a div for circular backgrounds, and color using background:
 
 ### Repository Preferences
 
-1. **Preferred**: Lucide out-of-box with color styling
+1. **Preferred**: Lucide out-of-the-box with color styling
 2. **Acceptable**: Lucide with stroke property adjustments
 3. **Last resort**: Custom `.svg` imports
 

docs/code-conventions.md

@@ -8,7 +8,7 @@ Utility functions (utils) should be defined in standalone files inside `src/lib/
 
 ## Scripts
 
-Scripts we use on build time and are not directly related to the source code (eg: Crowdin imports, GitHub tasks) should be defined in standalone files inside `src/scripts` dir.
+Scripts we use at build time and are not directly related to the source code (eg: Crowdin imports, GitHub tasks) should be defined in standalone files inside `src/scripts` dir.
 
 ## Constants
 
@@ -63,7 +63,7 @@ For the props type signature use the naming convention `<ComponentName>Props` to
 
 **Do not use `React.FC`** and instead annotate the props object directly. `React.FC` implies the `children` prop, but this is not always desired when there is a component that should not accept this prop. `React.FC` also does not allow for use of Generic types, or use of Generic type when doing type guarding like function overloading. It is also not generally recommended to use and [was removed from the create-react-app template](https://github.com/facebook/create-react-app/pull/8177).
 
-A positive side-effect to directly annotating the props object is for IDE intellisense where you can view the props when hovering over the component name to see it's signature.
+A positive side-effect to directly annotating the props object is for IDE intellisense where you can view the props when hovering over the component name to see its signature.
 
 i.e., `const Component: ({ label, title, ...props }: ComponentProps) => React.JSX.Element`
 

docs/deploy-process.md

@@ -9,7 +9,7 @@ The current process for deployment involves a 2-day QA cycle to test a release c
 The typical workflow is as follows:
 
 1. A branch is created off of the `dev` branch, and pull requests for the branch are created into `dev`
-2. Pull requests are reviewed, and merged into `dev`
+2. Pull requests are reviewed and merged into `dev`
 3. On Tuesday, a pull request is created into the `staging` branch
    - At this point, the `staging` branch will be the release candidate. At this point, no new features are added into staging for the release, only release blocking bugfixes.
 4. During the next 2 days (Tuesday - Thursday) QA testing on the release candidate takes place
@@ -19,7 +19,7 @@ The typical workflow is as follows:
 5. If any release blocking bugfixes are merged into `staging`, bring those changes into `dev`
 6. When a release candidate is ready for release, merge into `master` and deploy to production on Thursday
 7. Create a tag for the new version in master
-8. Merge tag into `staging` and `dev`
+8. Merge the tag into `staging` and `dev`
 
 ```
 master  O (tag) - - - - - - - - - - - - O (tag)
@@ -44,7 +44,7 @@ feature 2             \ _ _  O
 In the event that a bug was found in `staging` during the QA cycle that blocks a release, the following steps will take place to address the bug:
 
 1. Create an issue in GitHub documenting the bug
-2. Triage issue to a developer
+2. Triage the issue to a developer
 3. Developer will create a branch off of `staging`
 4. Work on bugfix
 5. Create a pull request into `staging`
@@ -69,14 +69,14 @@ dev     O - - - - O - - O - O - - - O - - - - - O
 
 ## Hotfix process
 
-In the event that a hotfix is found in production and needs to be addressed before the next release
+In the event that a hotfix is found in production and needs to be addressed before the next release.
 
 1. Create an issue in GitHub documenting the bug
 2. Triage issue to a developer
 3. Developer will create a branch off of `master`
 4. Work on hotfix
 5. Create a pull request into `master`
-6. After review, merge hotfix pull request into `master` and release into production
+6. After review, merge the hotfix pull request into `master` and release into production
 7. Merge `master` into `staging` and `dev` branches
 
 ```

docs/editing-markdown.md

@@ -9,7 +9,7 @@
 - Editing MD files
   - Markdown is somewhat similar to HTML, you can use `#` for `h1` which is the largest heading or `##` for `h2`.
   - Here's a little [guide](https://www.markdownguide.org/cheat-sheet/) for better understanding of the same.
-  - You can directly edit these files on GitHub and can preview by clicking on the preview button.
+  - You can directly edit these files on GitHub and preview them by clicking on the preview button.
 - Scroll down, write a brief description about the changes you made and click on `Propose Changes`.
 - Click on `Create pull request` and wait for the reviewers to review your PR.
   ![create-pull-request](https://user-images.githubusercontent.com/55744578/136703597-6644e43c-7c64-4cc0-bf8b-7fb8db9544cf.jpg)

docs/event-tracking.md

@@ -29,7 +29,7 @@ Ideally, ask yourself what design decision/assumptions have been made on the pag
 - form fields abandoned
 - scroll behavior down a page
 
-This data can be later used to decide whether a feature is being used or is underperforming.
+This data can later be used to decide whether a feature is being used or is underperforming.
 
 It's helpful to ask yourself how the results of what we track and measure might influence our decision-making. For example, measuring something that won't help us make concrete product decisions is probably not worth tracking.
 
@@ -91,7 +91,7 @@ Can be used to get more info on the UX.
 
 Examples:
 
-- Use it to track the average position of clicked search result
+- Use it to track the average position of clicked search results
 - What terms are entered into the search field
 - Which option is chosen from a dropdown menu
 - How many or what filters are applied when filtering the list of wallets

docs/github-issue-triage-process.md

@@ -11,8 +11,8 @@ Whenever a new issue is opened, it will automatically be labeled with a `needs t
 The core team will review issues with the `needs triage 📥` label within 5 days. In order for an issue to be considered triaged, one of the following will need to happen:
 
 1. The issue will be closed if it is not needed, a duplicate, or spam.
-2. If an issue needs more discussion, the `GH grooming` tag will be added, and the issue will be discussed next GitHub grooming. After this call, action items will be recorded and the issue will be considered triaged.
-3. The issue is labeled with the appropriate tags for work needed (ex: `design required`, `dev required`, etc.) and open it up for assignment. More on this below.
+2. If an issue needs more discussion, the `GH grooming` tag will be added, and the issue will be discussed at the next GitHub grooming. After this call, action items will be recorded and the issue will be considered triaged.
+3. The issue is labeled with the appropriate tags for work needed (ex: `design required`, `dev required`, etc.) and is opened up for assignment. More on this below.
 
 After an issue has been triaged, the `needs triage 📥` label will be removed from the issue.