Turn repeated thread locality content into an include (#11554)

* Turn repeated thread locality content into an include

* Update includes/platforms/configuration/options/thread-locality.mdx

Co-authored-by: Liza Mock <[email protected]>

---------

Co-authored-by: Alex Krawiec <[email protected]>
Co-authored-by: James Crosswell <[email protected]>
Co-authored-by: Liza Mock <[email protected]>

Author: 4 people

docs/platforms/dotnet/common/enriching-events/scopes/index.mdx

@@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
 time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
-<Alert>
-
-If you are very curious about how thread locality works for scope data, in .NET there
-are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
-most appropriate mode for your application type. However this can be overridden by
-setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
-
-If global mode is disabled (appropriate for most server based applications), the
-ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
-context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
-explains that concept in more detail.
-
-If global mode is enabled (appropriate for desktop applications), ambient scope data is
-stored as a Singleton and available globally. This means you can set context (such as
-the user logged into the application) once and it will be sent with all events, regardless
-of whether the event was captured on the UI thread or a background thread.
-
-</Alert>
+<Include name="platforms/configuration/options/thread-locality.mdx" />
 
 When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
 discovers the current hub and asks it to capture an event. Internally the hub will

docs/platforms/powershell/enriching-events/scopes/index.mdx

@@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
 time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
-<Alert>
-
-If you are very curious about how thread locality works for scope data, in .NET there
-are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
-most appropriate mode for your application type. However this can be overridden by
-setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
-
-If global mode is disabled (appropriate for most server based applications), the
-ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
-context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
-explains that concept in more detail.
-
-If global mode is enabled (appropriate for desktop applications), ambient scope data is
-stored as a Singleton and available globally. This means you can set context (such as
-the user logged into the application) once and it will be sent with all events, regardless
-of whether the event was captured on the UI thread or a background thread.
-
-</Alert>
+<Include name="platforms/configuration/options/thread-locality.mdx" />
 
 When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
 discovers the current hub and asks it to capture an event. Internally the hub will

docs/platforms/unity/enriching-events/scopes/index.mdx

@@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
 time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
-<Alert>
-
-If you are very curious about how thread locality works for scope data, in .NET there
-are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
-most appropriate mode for your application type. However this can be overridden by
-setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
-
-If global mode is disabled (appropriate for most server based applications), the
-ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
-context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
-explains that concept in more detail.
-
-If global mode is enabled (appropriate for desktop applications), ambient scope data is
-stored as a Singleton and available globally. This means you can set context (such as
-the user logged into the application) once and it will be sent with all events, regardless
-of whether the event was captured on the UI thread or a background thread.
-
-</Alert>
+<Include name="platforms/configuration/options/thread-locality.mdx" />
 
 When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
 discovers the current hub and asks it to capture an event. Internally the hub will

includes/platforms/configuration/options/thread-locality.mdx

@@ -0,0 +1,16 @@
+<Alert>
+
+Read on if you're curious to know how thread locality works for scope data. In .NET, there
+are two modes for managing ambient data (which is data that's available in different parts of an application and doesn't need to be passed explicitly through method arguments): a disabled global mode and an enabled global mode. Usually, Sentry will automatically choose the most appropriate mode for your application type. However, this can be overridden by setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
+
+If global mode is disabled (appropriate for most server-based applications), the
+ambient scope data will be stored as an `AsyncLocal` and will flow with the execution
+context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
+explains that concept in more detail.
+
+If global mode is enabled (appropriate for desktop applications), ambient scope data will be
+stored as a Singleton and available globally. This means you can set context (such as
+the user logged into the application) once and it will be sent with all events, regardless
+of whether the event was captured on the UI thread or a background thread.
+
+</Alert>