remove weird usages of non breaking space <0xa0> (#5560)

src/docs/product/data-management-settings/filtering/index.mdx

@@ -16,7 +16,7 @@ Sentry provides several methods to filter data in your project. Using sentry.io
 
 ## Inbound Data Filters
 
-Inbound data filters allow you to determine which errors, if any, Sentry should ignore. Explore these by navigating to **[Project] > Project Settings > Inbound Filters.**
+Inbound data filters allow you to determine which errors, if any, Sentry should ignore. Explore these by navigating to **[Project] > Project Settings > Inbound Filters.**
 
 These filters are exclusively applied at ingest time and not later in processing. This, for instance, lets you discard an error by error message when the error is ingested through the JSON API. On the other hand, this filter doesn't apply to ingested minidumps. Filtered events do not consume quota, as discussed in [What Counts Toward My Quota](/product/accounts/quotas/#what-counts-toward-my-quota-an-overview).
 

src/docs/product/integrations/cloud-monitoring/aws-lambda/index.mdx

@@ -150,10 +150,10 @@ custom:
 
 functions:
   <yourFunctionName>:
-    handler: sentry_sdk.integrations.init_serverless_sdk.sentry_lambda_handler
-    environment:
-      SENTRY_INITIAL_HANDLER: '<yourLambdaHandlerFunctionPath>'
-    layers: ${self:custom.layers}
+    handler: sentry_sdk.integrations.init_serverless_sdk.sentry_lambda_handler
+    environment:
+      SENTRY_INITIAL_HANDLER: '<yourLambdaHandlerFunctionPath>'
+    layers: ${self:custom.layers}
 ```
 
 Currently there is no way of using the [latest layer plugin](https://www.npmjs.com/package/serverless-latest-layer-version) since the  lambda:ListLayerVersions on resource: arn:aws:lambda:eu-west-1:943013980633:layer:SentryNodeServerlessSDK has not been given the necessary permissions.

src/docs/product/issues/issue-owners/index.mdx

@@ -19,7 +19,7 @@ Ownership rules and code owners are matched against individual events in an issu
 
 ### Ownership Rules
 
-You define ownership rules per project. To configure ownership rules, navigate to your **[Project] > Settings > Issue Owners**, or click on the "Create Ownership Rule" button on an Issue Details page.
+You define ownership rules per project. To configure ownership rules, navigate to your **[Project] > Settings > Issue Owners**, or click on the "Create Ownership Rule" button on an Issue Details page.
 
 Types of matches available:
 
@@ -38,7 +38,7 @@ The general format of a rule is: `type:pattern owners`
 
 : The pattern you're matching on. For example, `src/javascript/*` for `path`, `[https://www.example.io/checkout](https://www.example.io/checkout)` for `url`, or `Chrome 81.0.*` for `tags.browser`.
 
-: `pattern` matching supports unix-style [glob syntax](<https://en.wikipedia.org/wiki/Glob_(programming)>). For example, add `*` to match anything and `?` to match a single character. *This is not a regex.*
+: `pattern` matching supports unix-style [glob syntax](<https://en.wikipedia.org/wiki/Glob_(programming)>). For example, add `*` to match anything and `?` to match a single character. *This is not a regex.*
 
 `owners`
 

src/docs/product/profiling/index.mdx

@@ -23,17 +23,17 @@ Profiling allows you to collect and analyze performance profiles from real user
 
 The typical approach to measuring app performance involves setting up automated performance tests for various user flows that run during continuous integration (CI), or manually profiling hot paths in your app using tools like Apple Instruments or Android Profiler. These are excellent tools, but they have numerous drawbacks:
 
-- **The environment is near-optimal and highly controlled.** Developers often use the latest, most powerful devices, and are testing apps on excellent network conditions. These conditions do not always reflect real world performance scenarios — users may be running your app on low-end hardware, older operating system versions, or poor network conditions. These conditions can be simulated to some extent, but the complete matrix of variables is too large to be able to test every case on a regular basis.
-- **Only a subset of user flows are being tested.** Performance tests are typically set up for the most common user flows, but it's impractical to build and maintain tests for every possible way someone might be using your app.
-- **Metrics are calculated based on a small number of samples.** Performance metrics are often calculated by aggregating the results from a small number of runs. While this can be sufficient in some cases, it may not be enough data to give you an accurate, statistically significant measurement, especially if you need to account for different hardware, thermal conditions, and so on.
-- **The process is difficult and time consuming.** Manually conducting extensive performance tests on your app before every release is time consuming. Building and maintaining automated performance tests is also time consuming. Interpreting the results can be difficult and frustrating for someone who's not a performance specialist and is unfamiliar with the tools or the process.
+- **The environment is near-optimal and highly controlled.** Developers often use the latest, most powerful devices, and are testing apps on excellent network conditions. These conditions do not always reflect real world performance scenarios — users may be running your app on low-end hardware, older operating system versions, or poor network conditions. These conditions can be simulated to some extent, but the complete matrix of variables is too large to be able to test every case on a regular basis.
+- **Only a subset of user flows are being tested.** Performance tests are typically set up for the most common user flows, but it's impractical to build and maintain tests for every possible way someone might be using your app.
+- **Metrics are calculated based on a small number of samples.** Performance metrics are often calculated by aggregating the results from a small number of runs. While this can be sufficient in some cases, it may not be enough data to give you an accurate, statistically significant measurement, especially if you need to account for different hardware, thermal conditions, and so on.
+- **The process is difficult and time consuming.** Manually conducting extensive performance tests on your app before every release is time consuming. Building and maintaining automated performance tests is also time consuming. Interpreting the results can be difficult and frustrating for someone who's not a performance specialist and is unfamiliar with the tools or the process.
 
 Profiling is designed to address all of these issues:
 
-- **The environments are diverse and reflect real world conditions.** We collect performance data automatically from every environment that your app is running on in the real world, accounting for different device hardware, OS versions, app versions, network conditions, and more.
-- **We cover the widest possible set of user flows.** Since the data is collected from actual users using your app as they normally would, we can capture all kinds of usage patterns that you may not have thought about when building your own performance tests.
-- **Metrics are calculated using a large number of samples.** We can collect data from up to 100% of your user population in production, allowing us to compute more accurate metrics.
-- **The process is simple.** Integrate the Sentry SDK, enable profiling, ship your app, and let us worry about analyzing performance and detecting regressions between versions. We encourage *testing in production*, which improves developer velocity and reduces the overhead of having to maintain your own tests and tooling. Our dashboard is designed to be approachable to all engineers, and not just people who have a performance engineering background.
+- **The environments are diverse and reflect real world conditions.** We collect performance data automatically from every environment that your app is running on in the real world, accounting for different device hardware, OS versions, app versions, network conditions, and more.
+- **We cover the widest possible set of user flows.** Since the data is collected from actual users using your app as they normally would, we can capture all kinds of usage patterns that you may not have thought about when building your own performance tests.
+- **Metrics are calculated using a large number of samples.** We can collect data from up to 100% of your user population in production, allowing us to compute more accurate metrics.
+- **The process is simple.** Integrate the Sentry SDK, enable profiling, ship your app, and let us worry about analyzing performance and detecting regressions between versions. We encourage *testing in production*, which improves developer velocity and reduces the overhead of having to maintain your own tests and tooling. Our dashboard is designed to be approachable to all engineers, and not just people who have a performance engineering background.
 - **The overhead is minimal.** Depending on the platform, the overhead can be lower than 1% of your app’s CPU time.
 
 ## Learn More

src/docs/product/projects/index.mdx

@@ -8,7 +8,7 @@ A _Project_ represents your service or application in Sentry. For example, you m
 
 You can [create a project](/product/sentry-basics/integrate-frontend/create-new-project/) for a service and select the particular language or framework when you first start using Sentry. You can add more projects on an as-needed basis, for example, if you want to manage access permissions and/or control privacy and data settings. Setting up multiple projects to reflect your application landscape with finer granularity will go a long way in helping with visibility and triage. Learn more about best practices for setting up projects in our [account setup documentation](/product/accounts/getting-started/#4-create-projects).
 
-When displaying the **Issue Stream** and **Discover** views, the top-level filter bar considers the projects you are a member of by default. This way, you are looking at information that is immediately relevant to your work.
+When displaying the **Issue Stream** and **Discover** views, the top-level filter bar considers the projects you are a member of by default. This way, you are looking at information that is immediately relevant to your work.
 
 Projects differ from [environments](/product/sentry-basics/environments/), which are designed to help triage issues, especially in a multi-staged release process.
 

src/docs/product/releases/setup/release-automation/circleci/index.mdx

@@ -25,9 +25,9 @@ Click "Save", then record your token, which you'll need in the next section.
 
 Next, you'll need a few environment variables to configure the Sentry CLI:
 
-- `SENTRY_AUTH_TOKEN` - Your internal integration token
-- `SENTRY_ORG` - Your Sentry organization slug
-- `SENTRY_PROJECT` - Your Sentry project slug
+- `SENTRY_AUTH_TOKEN` - Your internal integration token
+- `SENTRY_ORG` - Your Sentry organization slug
+- `SENTRY_PROJECT` - Your Sentry project slug
 
 To access your internal integration token securely, store it as an [environment variable on your project](https://circleci.com/docs/2.0/env-vars/#setting-an-environment-variable-in-a-project):
 
@@ -70,6 +70,6 @@ For more details about the release management concepts in the snippet above, see
 
 **Notes**:
 
-- If you’re not deploying a project that requires source maps or you've sent source maps to Sentry using another method, omit the `upload-sourcemaps` line.
-- If you can’t install a repository integration, send commit metadata using the [create release endpoint](/product/releases/suspect-commits/#using-the-api) or omit the `set-commits` line.
-- `sentry-cli releases propose-version` defaults to the commit SHA of the commit being deployed. To set this to a different version, modify `SENTRY_RELEASE` to the preferred version.
+- If you’re not deploying a project that requires source maps or you've sent source maps to Sentry using another method, omit the `upload-sourcemaps` line.
+- If you can’t install a repository integration, send commit metadata using the [create release endpoint](/product/releases/suspect-commits/#using-the-api) or omit the `set-commits` line.
+- `sentry-cli releases propose-version` defaults to the commit SHA of the commit being deployed. To set this to a different version, modify `SENTRY_RELEASE` to the preferred version.

src/docs/product/releases/setup/release-automation/jenkins/index.mdx

@@ -25,9 +25,9 @@ Click "Save", then record your token, which you'll need in the next section.
 
 To access your internal integration token securely in Jenkins, store it as a [credential](https://www.jenkins.io/doc/book/using/using-credentials/):
 
-1. From the Jenkins home page (the Dashboard of the classic Jenkins UI), click **Credentials > System**.
-2. Under **System**, click the **Global credentials (unrestricted)** link to access this default domain.
-3. Click **Add Credentials**.
+1. From the Jenkins home page (the Dashboard of the classic Jenkins UI), click **Credentials > System**.
+2. Under **System**, click the **Global credentials (unrestricted)** link to access this default domain.
+3. Click **Add Credentials**.
 4. From the **Kind** field select Secret Text.
 5. Give your credential an **ID** (for example, "sentry-auth-token") and in the **Secret** field paste your internal integration token.
 6. Click **OK** to save the credentials.
@@ -81,8 +81,8 @@ pipeline {
 
 **Notes**:
 
-- If you’re not deploying a project that requires source maps or you've sent source maps to Sentry using another method, omit the `upload-sourcemaps` line.
-- If you can’t install a repository integration, send commit metadata via the [create release endpoint](/product/releases/suspect-commits/#using-the-api) or omit the `set-commits` line.
+- If you’re not deploying a project that requires source maps or you've sent source maps to Sentry using another method, omit the `upload-sourcemaps` line.
+- If you can’t install a repository integration, send commit metadata via the [create release endpoint](/product/releases/suspect-commits/#using-the-api) or omit the `set-commits` line.
 - `credentials('sentry-auth-token')` refers to the ID of the credentials just added to Jenkins.
 - `sentry-cli releases propose-version` defaults to the commit SHA of the commit being deployed. To set this to a different version, modify `SENTRY_RELEASE` to the preferred version.
 
@@ -115,6 +115,6 @@ If you're using Freestyle projects, you need to add another build step after dep
 
    **Notes**:
 
-   - If you’re not deploying a project that requires source maps or you've sent source maps to Sentry using another method, omit the `upload-sourcemaps` line.
-   - If you can’t install a repository integration, send commit metadata via the [create release endpoint](/product/releases/suspect-commits/#using-the-api) or omit the `set-commits` line.
+   - If you’re not deploying a project that requires source maps or you've sent source maps to Sentry using another method, omit the `upload-sourcemaps` line.
+   - If you can’t install a repository integration, send commit metadata via the [create release endpoint](/product/releases/suspect-commits/#using-the-api) or omit the `set-commits` line.
    - `sentry-cli releases propose-version` defaults to the commit SHA of the commit being deployed. To set this to a different version, modify `SENTRY_RELEASE` to the preferred version.

src/docs/product/releases/setup/release-automation/travis-ci/index.mdx

@@ -25,9 +25,9 @@ Click "Save", then record your token, which you'll need in the next section.
 
 Next, you'll need a few environment variables to configure the Sentry CLI:
 
-- `SENTRY_AUTH_TOKEN` - Your internal integration token
-- `SENTRY_ORG` - Your Sentry organization slug
-- `SENTRY_PROJECT` - Your Sentry project slug
+- `SENTRY_AUTH_TOKEN` - Your internal integration token
+- `SENTRY_ORG` - Your Sentry organization slug
+- `SENTRY_PROJECT` - Your Sentry project slug
 
 To access your internal integration token securely, store it as an [environment variable on your repository](https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-settings):
 
@@ -63,6 +63,6 @@ For more details about the release management concepts in the snippet above, see
 
 **Notes**:
 
-- If you’re not deploying a project that requires source maps or you've sent source maps to Sentry using another method, omit the `upload-sourcemaps` line.
-- If you can’t install a repository integration, send commit metadata via the [create release endpoint](/product/releases/suspect-commits/#using-the-api) or omit the `set-commits` line (`set-commits` is required for suspect commits).
-- `sentry-cli releases propose-version` defaults to the commit SHA of the commit being deployed (recommended). To set this to a different version, modify `SENTRY_RELEASE` to the preferred version.
+- If you’re not deploying a project that requires source maps or you've sent source maps to Sentry using another method, omit the `upload-sourcemaps` line.
+- If you can’t install a repository integration, send commit metadata via the [create release endpoint](/product/releases/suspect-commits/#using-the-api) or omit the `set-commits` line (`set-commits` is required for suspect commits).
+- `sentry-cli releases propose-version` defaults to the commit SHA of the commit being deployed (recommended). To set this to a different version, modify `SENTRY_RELEASE` to the preferred version.

src/docs/product/sentry-basics/enrich-data/index.mdx

@@ -81,7 +81,7 @@ You'll be able to reduce noise by pinpointing notifications to the right people
 
 ### Release Workflows
 
-Configuring the release version ID on the SDK will associate every error that happens in your application runtime with a specific release version of your code. This way, you know exactly when an error was introduced into your source code. It also unlocks these powerful features and workflows:
+Configuring the release version ID on the SDK will associate every error that happens in your application runtime with a specific release version of your code. This way, you know exactly when an error was introduced into your source code. It also unlocks these powerful features and workflows:
 
 1. **Suspect Commits & Suggested Assignee** - With a release in place, Sentry can suggest suspect commits that might have an introduced the error into your code and, through that commit, also suggest the author as an assignee.
 2. **Resolve With Release** - When you mark an issue as resolved in a specific release, new events of that issue occurring in previous releases will be ignored and will not trigger any notifications.

src/docs/product/sentry-basics/environments/index.mdx

@@ -25,7 +25,7 @@ Sentry automatically creates environments when it receives an event with the env
 
 ### Issues
 
-If an issue has events from multiple environments, the issue will appear when you select any of those environments. Sentry defines an issue as a grouping of similar events. If you tag one or more events within an issue with a specific environment, that issue will appear in your view when filtered by that environment. For example, if an issue is composed of one event tagged with `Production` and one event tagged with `Staging`, the issue will appear in your view when filtering by `Production`, as well as by `Staging`.
+If an issue has events from multiple environments, the issue will appear when you select any of those environments. Sentry defines an issue as a grouping of similar events. If you tag one or more events within an issue with a specific environment, that issue will appear in your view when filtered by that environment. For example, if an issue is composed of one event tagged with `Production` and one event tagged with `Staging`, the issue will appear in your view when filtering by `Production`, as well as by `Staging`.
 
 Also, the environment filter affects all issue-related metrics, such as the count of users affected, times series graphs, and event count.