Update docs/platforms/javascript/common/sourcemaps/troubleshooting_js/debug-ids/index.mdx

Co-authored-by: Luca Forstner <[email protected]>

Author: priscilawebdev

docs/platforms/javascript/common/sourcemaps/troubleshooting_js/debug-ids/index.mdx

@@ -11,7 +11,7 @@ Modern web applications often use some kind of build process when using JavaScri
 
 As a result, the JavaScript code running in production is typically not the same as the code written by the developer in the source editor. Instead, it has undergone several transformations, such as minification, transpilation, downcompilation, bundling, polyfilling, and others, aimed at improving performance and ensuring cross-browser compatibility. Some common tools that transform code in such ways are Babel, Vite, Webpack, Rollup, Terser or swc - which are often used by higher level tools like Next.js, Nuxt, Create React App and similar.
 
-Stack traces are essential to debug errors, but stack traces that come from generated JavaScript are often unreadable or unusable! They look nothing like the code you wrote, you can’t connect them to your source code repository, and minified variables or function names make you lose context about what is happening.
+Stack traces are essential to debug errors, but stack traces that come from generated JavaScript are often unreadable or unusable! They look nothing like the code you wrote and you can't connect them to your source code repository.
 
 To ensure Sentry (and other tools) can provide stack traces that are both readable and useful, you’ll want to generate and use [source maps](https://firefox-source-docs.mozilla.org/devtools-user/debugger/how_to/use_a_source_map/index.html). Source maps are files that map the transformed JavaScript back to the original code. This allows Sentry to trace the error to your original source, which means you’ll get stack traces that look like the code you wrote, not the code you generated.