fix(content): unify usage of i.e. and e.g. (#7653)

Uniform usage of i.e. and e.g. across docs

Author: Uaitt

apps/site/pages/en/blog/npm/npm-1-0-link.md

@@ -106,7 +106,7 @@ I highly doubt that a native Windows node will ever have comparable symbolic lin
 
 When there is a native windows port of Node, if that native windows port has `fs.symlink` and `fs.readlink` support that is exactly identical to the way that they work on Unix, then this should work fine.
 
-But I wouldn't hold my breath. Any bugs about this not working on a native Windows system (ie, not Cygwin) will most likely be closed with `wontfix`.
+But I wouldn't hold my breath. Any bugs about this not working on a native Windows system (i.e., not Cygwin) will most likely be closed with `wontfix`.
 
 ## <!-- aside_credit_where_credit8217s_due -->Aside: Credit where Credit’s Due
 

apps/site/pages/en/blog/release/v0.10.0.md

@@ -156,7 +156,7 @@ http/simple.js type=buffer length=102400: <span style="background-color:#0f0;col
 </pre>
 
 What we see here is that, overall, HTTP is faster. It's just slightly
-slower (1-5%) when sending extremely large string messages (ie
+slower (1-5%) when sending extremely large string messages (i.e.
 `type=bytes` rather than `type=buffer`). But otherwise, things are
 about the same, or slightly faster.
 

apps/site/pages/en/blog/vulnerability/october-2023-security-releases.md

@@ -15,7 +15,7 @@ following issues.
 
 Undici did not always clear Cookie headers on cross-origin redirects. By design, cookie headers are [forbidden request headers](https://fetch.spec.whatwg.org/#forbidden-request-header), disallowing them to be set in RequestInit.headers in browser environments. Since undici handles headers more liberally than the spec, there was a disconnect from the assumptions the spec made, and undici's implementation of fetch.
 
-As such this may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the 3rd party site.
+As such this may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (i.e. an open redirector) to leak the cookie to the 3rd party site.
 
 More details area available in [GHSA-wqq4-5wpv-mx2g](https://github.com/nodejs/undici/security/advisories/GHSA-wqq4-5wpv-mx2g)
 

apps/site/pages/en/learn/getting-started/nodejs-with-webassembly.md

@@ -12,7 +12,7 @@ The WebAssembly specification details two file formats, a binary format called a
 
 ## Key Concepts
 
-- Module - A compiled WebAssembly binary, ie a `.wasm` file.
+- Module - A compiled WebAssembly binary, i.e. a `.wasm` file.
 - Memory - A resizable ArrayBuffer.
 - Table - A resizable typed array of references not stored in Memory.
 - Instance - An instantiation of a Module with its Memory, Table, and variables.

apps/site/pages/en/learn/modules/publishing-a-package.mdx

@@ -539,7 +539,7 @@ So when you see configuration options citing or named with `require` or `import`
 
 ⚠️ Adding an `"exports"` field/field-set to a package’s configuration effectively [blocks deep pathing into the package](https://nodejs.org/api/packages.html#package-entry-points) for anything not explicitly listed in the exports’ subpathing. This means it can be a breaking change.
 
-⚠️ Consider carefully whether to distribute both CJS and ESM: It creates the potential for the [Dual Package Hazard](#the-dual-package-hazard) (especially if misconfigured and the consumer tries to get clever). This can lead to an extremely confusing bug in consuming projects, especially when your package is not perfectly configured. Consumers can even be blind-sided by an intermediary package that uses the "other" format of your package (eg consumer uses the ESM distribution, and some other package the consumer is also using itself uses the CJS distribution). If your package is in any way stateful, consuming both the CJS and ESM distributions will result in parallel states (which is almost surely unintentional).
+⚠️ Consider carefully whether to distribute both CJS and ESM: It creates the potential for the [Dual Package Hazard](#the-dual-package-hazard) (especially if misconfigured and the consumer tries to get clever). This can lead to an extremely confusing bug in consuming projects, especially when your package is not perfectly configured. Consumers can even be blind-sided by an intermediary package that uses the "other" format of your package (e.g. consumer uses the ESM distribution, and some other package the consumer is also using itself uses the CJS distribution). If your package is in any way stateful, consuming both the CJS and ESM distributions will result in parallel states (which is almost surely unintentional).
 
 ### The dual-package hazard
 

apps/site/pages/en/learn/typescript/publishing-a-ts-package.md

@@ -136,7 +136,7 @@ const bar: number = 1 + foo;
 
 TypeScript has warned that the above code will not behave as intended, just like a unit test warns that code does not behave as intended. They are complementary and verify different things—you should have both.
 
-Your editor (eg VS Code) likely has built-in support for TypeScript, displaying errors as you work. If not, and/or you missed those, CI will have your back.
+Your editor (e.g. VS Code) likely has built-in support for TypeScript, displaying errors as you work. If not, and/or you missed those, CI will have your back.
 
 The following [GitHub Action](https://github.com/features/actions) sets up a CI task to automatically check (and require) types pass inspection for a PR into the `main` branch.
 

apps/site/scripts/release-post/index.mjs

@@ -174,7 +174,7 @@ const verifyDownloads = version =>
   Promise.all(downloadsTable(version).map(urlOrComingSoon));
 
 const findAuthorLogin = (version, section) => {
-  // looking for the @author part of the release header, eg:
+  // looking for the @author part of the release header, e.g.:
   // ## 2016-03-08, Version 5.8.0 (Stable). @Fishrock123
   // ## 2015-10-13, Version 4.2.1 'Argon' (LTS), @jasnell
   // ## 2015-09-08, Version 4.0.0 (Stable), @rvagg